Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Saved Objects Management] Encapsulate saved objects deletion behind an API endpoint #148602

Merged
merged 8 commits into from
Jan 19, 2023

Conversation

dokmic
Copy link
Contributor

@dokmic dokmic commented Jan 9, 2023

Summary

Resolves #148615.

The API endpoint delegates the delete operation to the bulkDelete (#139680) method of the SO client on the server.

Checklist

@dokmic dokmic added review Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc release_note:skip Skip the PR/issue when compiling release notes Feature:Saved Objects Management v8.7.0 labels Jan 9, 2023
@dokmic dokmic force-pushed the feature/KBNA-7991 branch from 9ab4332 to 22899e3 Compare January 10, 2023 11:57
@dokmic dokmic marked this pull request as ready for review January 10, 2023 13:42
@dokmic dokmic requested a review from a team as a code owner January 10, 2023 13:42
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-core (Team:Core)

Copy link
Contributor

@TinaHeiligers TinaHeiligers left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall, great work!

We need to make sure we don't accidentally call bulk_delete for hidden saved objects. The API won't recognize those and we should give the impression that one can delete hidden objects from SOM.

deleteStatus
.filter(({ success }) => !success)
.forEach(({ id, type, error }) => {
notifications.toasts.addDanger({
Copy link
Contributor

@TinaHeiligers TinaHeiligers Jan 10, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Adding a toast for every failed delete is going to get very noisy for large payloads. It's not a problem for single-item deletes but might cause toast floods for multiple delete failures.

This comment was marked as resolved.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alright, I've updated the code to show a single toast only. But I have some concerns that it's better. It seems like we are hiding from the user all the errors we've got during the deletion.
IMO, it's okay to show a toast per each failed operation as we perform it only for the manually selected objects which should not be more than 50 in the worst case.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

which should not be more than 50 in the worst case

With anything related to saved objects, we cannot assume that. If there aren't any objections from other members of the team, go with what you 'feel' is right.

http: HttpStart,
objects: SavedObjectDeleteRequest[]
): Promise<SavedObjectDeleteStatus[]> {
return http.post<SavedObjectDeleteStatus[]>('/api/kibana/management/saved_objects/_bulk_delete', {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The repository won't recognize hidden saved object types as those aren't recognized as registered unless the hidden types are included. We're not instantiating the client with any hidden types and will need to filter these out in a similar manner as:
https://github.com/elastic/kibana/pull/148602/files#diff-47d724c5a7bb6e8c1286f67e3ed1b117ac27e05387052760388bd477bd76337bL525

    const deletes = selectedSavedObjects
      .filter((object) => !object.meta.hiddenType)
      .map((object) => savedObjectsClient.delete(object.type, object.id, { force: true }));
    await Promise.all(deletes);

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now that we have a dedicated endpoint, we could use a custom client with all hidden types. Not sure if we should, though.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I implemented that at first but then removed it to keep the existing behavior exactly the same. Just wanted to confirm whether should we ever provide such an option as hidden objects deletion.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just wanted to confirm whether should we ever provide such an option as hidden objects deletion.

Right now, IMHO, no. There are far too many issues that could cause. Type owners specifically register their saved objects as hidden to implement their own APIs and handle dependencies themselves. I don't think we could or even should bypass that and blindly allow users to shoot themselves in the foot. Preventing issues from editing saved objects in SOM is why we changed the edit to view-only in the first place.

Maybe, if we had object-level security we could implement it or even some other "advanced, super scary uber auth" where we have a registry of hidden types' delete APIs to use as the underlying implementation?

Copy link
Contributor

@rudolf rudolf Jan 19, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 to keep the behaviour as is. In general / long term, I would lean towards removing the delete ability for most types in management and moving that to their listing UIs which I think is also part of content management's vision.

http: HttpStart,
objects: SavedObjectDeleteRequest[]
): Promise<SavedObjectDeleteStatus[]> {
return http.post<SavedObjectDeleteStatus[]>('/api/kibana/management/saved_objects/_bulk_delete', {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now that we have a dedicated endpoint, we could use a custom client with all hidden types. Not sure if we should, though.

deleteStatus
.filter(({ success }) => !success)
.forEach(({ id, type, error }) => {
notifications.toasts.addDanger({

This comment was marked as resolved.

@dokmic dokmic force-pushed the feature/KBNA-7991 branch from 7b579b5 to 607c3b6 Compare January 18, 2023 20:47
@dokmic
Copy link
Contributor Author

dokmic commented Jan 18, 2023

@TinaHeiligers @pgayvallet I've updated the PR with some fixes based on your feedback. Would you mind taking another look?

Copy link
Contributor

@TinaHeiligers TinaHeiligers left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I still need to pull the branch and test

@TinaHeiligers TinaHeiligers self-requested a review January 19, 2023 00:08
Copy link
Contributor

@TinaHeiligers TinaHeiligers left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code LGTM!

@dokmic dokmic force-pushed the feature/KBNA-7991 branch from 8e2dd86 to e8eb772 Compare January 19, 2023 10:58
@kibana-ci
Copy link
Collaborator

💚 Build Succeeded

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id before after diff
savedObjectsManagement 78 79 +1

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id before after diff
savedObjectsManagement 83.9KB 84.6KB +663.0B

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id before after diff
savedObjectsManagement 19.3KB 19.4KB +85.0B
Unknown metric groups

References to deprecated APIs

id before after diff
savedObjectsManagement 157 149 -8

History

  • 💔 Build #101224 failed 8e2dd86046991ad5fd73f36aac906aa784a55a98
  • 💚 Build #99155 succeeded 7b579b573f7263abc9897d46fba30a7bfd401fdb
  • 💔 Build #98996 failed 9ab433233de5d9d0497ec0c48c712e65592e7de0

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

@dokmic dokmic merged commit 091b15e into elastic:main Jan 19, 2023
@kibanamachine kibanamachine added the backport:skip This commit does not require backporting label Jan 19, 2023
@dokmic dokmic deleted the feature/KBNA-7991 branch January 19, 2023 14:05
wayneseymour pushed a commit to wayneseymour/kibana that referenced this pull request Jan 19, 2023
jloleysens added a commit that referenced this pull request Feb 2, 2023
## Summary

Part of preparing HTTP APIs and associated interfaces for versioning:

* Add domain-specific interfaces to the saved object management plugin
    * Add a V1 interface of domain types to `common`
    * Remove use of deprecated `SavedObject` type from public
* Follows on from #148602


Related #149098

Fixes #149495

---------

Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport:skip This commit does not require backporting Feature:Saved Objects Management release_note:skip Skip the PR/issue when compiling release notes review Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc v8.7.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

API Layer for saved objects management plugin
7 participants